Records in count key data (CKD) format comprise count, key and data fields of variable length, thereby creating records whose length varies primarily according to variations in length of the data field. By contrast, records in fixed-block-architecture (FBA) format comprise fixed-length blocks (commonly referred to as "fixed blocks"), with padding bytes used as necessary to fill out a record which does not fill a complete block.
In transferring data between a system and a storage medium through a buffer, it is customary to protect the data against buffer errors by appending cyclic redundancy code (CRC) check bytes to each grouping of data that can be independently read or written at the disk level. For CKD-formatted records, CRC check bytes are appended to each count field, key field and data field before it is stored in the buffer, and the CRC for each field is checked as it is read from the buffer. Similarly, for fixed-block records, CRC bytes are appended to each block of data before it is stored in the buffer and the CRC for each block is checked as it is read from the buffer.
It has become common in the disk drive industry for records that are transmitted to or from a storage subsystem in CKD format to be recorded on the storage medium in fixed-block format. This format change implies that there is a point at which data stored in a buffer is regarded by a processor as a sequence of variable length fields and by a user device, such as a recording disk, as a sequence of fixed blocks. CRC check bytes may be applied based on either format.
If CRC check bytes were appended on the basis of the CKD format, then checking of data read from the buffer in CKD format is straightforward. The CRC for each field is checked as that field is read from the buffer. However, when the data is to be transferred as one or more fixed blocks for recording on disk, the fixed blocks must be checked by reading and checking all CKD fields that contain any part of the blocks to be transferred. For example, if a fixed-length block were to contain the end of CKD field A, all of CKD field B and the beginning of CKD field C, then checking of that fixed block as it is read from the buffer would require reading all of CKD fields A, B and C. Alternatively, if CRC check bytes were appended on the basis of the fixed-block format, then entering a new CKD field would require, for blocks containing data from two or more CKD fields, reading and checking the block, updating the affected bytes, regenerating the check bytes and rewriting the block.
Insofar as applicants are aware, data has not been stored in a buffer as a composite of two different data record formats, such as CKD and FBA, with a common cyclic redundancy code to provide error protection.
U.S. Pat. No. 3,821,703 describes a method and means for translating a variable-length CKD-formatted record into a fixed-length block FBA-formatted record. Since the end of the variable-length CKD record will rarely, if ever, coincide with the end of a fixed-length block, a residual segment is required. Each residual segment comprises the final data bytes of the CKD record and also includes CRC check bytes as transferred through a buffer and padding bytes to complete the particular fixed-length block. An odd number or even number of CRC check bytes is appended according to whether the total number of fixed blocks is odd or even.
U.S. Pat. No. 5,301,304 discloses a method and means for reorienting records written into a buffer to create CKD-emulated records in FBA format by eliminating, from each CKD-formatted record, before it is written to disk, intrarecord gaps and bytes not essential for recreating the record in CKD format. An emulator calculates the number and location of fixed-length blocks required to store each CKD-emulated record in a virtual track on the disk. The CKD-emulated records are written from the buffer to disk via an FBA adaptor in fixed-length blocks containing (i) header data indicating whether or not a CKD-emulated record begins in that block, (ii) byte displacement address, and (iii) padding bytes between each set of adjacent CKD-emulated records, including bytes corresponding to interrecord gaps, to assure that the beginning of each respective CKD-emulated record has the same byte displacement from a reference location on a virtual track on the disk as it would have from an index on a physical track of a CKD-formatted disk. This permits each CKD-emulated record to be accessed in a single revolution of the FBA-formatted disk without requiring a special directory or map list.
There is a need for a method and means for (i) translating data from one format (such as CKD) to another format (such as FBA) reliably with less cost; (ii) eliminating the need for CRC checking, during updating of a record, of all fields except the affected fields of a CKD record contained in one or more fixed-length blocks; (iii) eliminating the need for CRC checking, during reading or updating of a fixed block, of any CKD data outside the boundaries of the block; and (iv) facilitating checking and updating by using the same cyclic redundancy code (CRC) for each CKD field and gap and fixed block to assure that each CKD field and gap are conditioned in the same manner (e.g., zeroed) to provide no contribution to the CRC calculation for the fixed block.